home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20010921-20020314 / 000112_fdc@watsun.cc.columbia.edu_Sun Nov 4 20:39:32 EST 2001.msg < prev    next >
Text File  |  2020-01-01  |  5KB  |  110 lines
  1. Article: 12930 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!watsun.cc.columbia.edu!fdc
  3. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  4. Newsgroups: comp.unix.sco.misc,comp.protocols.kermit.misc
  5. Subject: Re: Dropping DTR in OSR5
  6. Date: 5 Nov 2001 01:39:05 GMT
  7. Organization: Columbia University
  8. Lines: 93
  9. Message-ID: <9s4qjp$30k$1@newsmaster.cc.columbia.edu>
  10. References: <9s40rp$fdh$1@newsmaster.cc.columbia.edu> <3be5c667$0$439$8eec23a@newsreader.tycho.net> <20011104160917.A13779@mammoth.ca.caldera.com>
  11. NNTP-Posting-Host: watsun.cc.columbia.edu
  12. X-Trace: newsmaster.cc.columbia.edu 1004924345 3092 128.59.39.2 (5 Nov 2001 01:39:05 GMT)
  13. X-Complaints-To: postmaster@columbia.edu
  14. NNTP-Posting-Date: 5 Nov 2001 01:39:05 GMT
  15. Xref: newsmaster.cc.columbia.edu comp.unix.sco.misc:139888 comp.protocols.kermit.misc:12930
  16.  
  17. In article <20011104160917.A13779@mammoth.ca.caldera.com>,
  18. Bela Lubkin  <belal@caldera.com> wrote:
  19. : John DuBois wrote:
  20. : > ...
  21. : > Some problems in this area were fixed in 5.0.6a.  Please test on that
  22. : > release and see if you still encounter this problem.
  23. : 
  24. : While this is true, Frank likes to support every OS ever made.  I
  25. : believe he still builds binaries for SCO Xenix.  A solution which
  26. : requires users to have an OS less than a year old won't satisfy him...
  27. : 
  28. Strange but absolutely true.  People still run old -- even ancient --
  29. Unix OS's, including SCO Xenix.  Doctors' offices are a good place to
  30. look for computing antiques.  I know a doctor who runs his practice from
  31. an AT&T 3B2.  The billing package only runs there, the vendor disappeared
  32. decades ago...
  33.  
  34. : The OpenServer "sio" driver doesn't implement ispeed and ospeed as
  35. : separate entities.  The functions exist and the structures have all the
  36. : necessary members, but it doesn't pay attention to the input rate, only
  37. : the output rate.  At least, that's how it's _intended_ to work.
  38. :
  39. Aha, the truth comes out...  Strict POSIX on the outside, not so strict
  40. on the inside :-)
  41.  
  42. Actually a pet peeve of mine is how latter-day SCO header files (and
  43. most other vendors) are full of:
  44.  
  45.   #if !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE)
  46.  
  47. to keep you from getting at anything useful -- hardware flow control, for
  48. example.  In many cases also high serial speeds.  But I digress...
  49.  
  50. : I vaguely remember that you can get into trouble -- confuse the driver --
  51. : by trying to change both.  This might have been one of the things fixed in
  52. : rs506a.  But I think the problem can be avoided on all releases, by only
  53. : programming the output speed.  So, suppose you test with only changing
  54. : ospeed, see whether that makes a difference?
  55. : 
  56. I just tried this on 5.0.2 -- no difference.  DTR and RTS go down,
  57. but only DTR come back up.
  58.  
  59. : This also isn't a general solution.  There are third party drivers that
  60. : slot into the same ioctls, but _do_ correctly support independent i/o
  61. : speeds.  Does Kermit have any system-specific hint settings?  Something
  62. : like an OpenServer-specific "set ignore-ospeed", turned on by default?
  63. : "On" is the correct default since "sio" is the most common serial driver
  64. : on OpenServer, and split-speed usage is rather uncommon.
  65. : 
  66. The third-party drivers is a land I don't have a passport for.  Device
  67. names, lockfile conventions, who knows what else.  I have reams of
  68. correspondence on this stuff, and the conclusion is always "don't touch
  69. it".  I figure if Digi or Stallion or somebody wants Kermit to support
  70. their stuff, they'll contact me about it.
  71.  
  72. : And, if I'm wrong, you might try an even kludgier workaround (which also
  73. : might not work, but is definitely worth trying): after having performed
  74. : all the POSIXly correct incantations, i.e. after the 2nd tcsetattr() in
  75. : your pseudo-code above, force an extra open of the port:
  76. : 
  77. :   ...
  78. :   tcsetattr()
  79. :   if ((kludge_fd = open(the_port, O_RDONLY | O_NONBLOCK | O_NOCTTY)) >= 0)
  80. :     close(kludge_fd);
  81. : 
  82. : I'm pretty sure this will cause "sio" to get its house in order and
  83. : raise DTR (and the close shouldn't lower it, since the other open still
  84. : exists).  For debugging purposes you might need to put in a pause before
  85. : the close() to observe that DTR actually goes on -- I don't fully trust
  86. : my assertion that the close() won't lower it.
  87. : 
  88. In fact DTR comes back on, but RTS stays down, just as without the kludge.
  89. The kludge does make a difference in 5.0.5, however: it makes it act like
  90. 5.0.2 (without the kludge in 5.0.5, both DTR and RTS stayed down).
  91.  
  92. : One last thing.  There's a comment in the driver that implies that after
  93. : cycling the baud rate through 0, DTR might not come back up immediately;
  94. : might only come up when you output a character.  I'm pretty sure this is
  95. : fixed in rs506a, but for older releases, see whether outputting a NUL
  96. : after the 2nd tcsetattr() causes DTR to wake up.
  97. : 
  98. In 5.0.2 DTR came up anyway, but RTS does not come back up, even when you
  99. send bytes.   Ditto for 5.0.5 with and without all the above tricks.
  100.  
  101. In short there seems to be no way to do this in OSR5 prior to 5.0.6a.  Hard
  102. to believe, right?  But not surprising either since I think Kermit must be
  103. the only program that would want to momentarily drop DTR without closing the
  104. device (and of course the problem with closing the device is that you've
  105. lost all the myriad setups you've done on it when you reopen it).
  106.  
  107. Thanks!
  108.  
  109. - Frank
  110.